In computerized environments such as the Microsoft Windows™ platform produced by the Microsoft Corporation of Redmond, Wash., multiple computer applications are often utilized by a user simultaneously. The multiple computer applications may include a variety of types of applications for communications, information, media or other purposes. Multimedia applications have become increasingly popular and generally demand a large amount of memory in order to run smoothly. Often, with multiple applications launched simultaneously, memory becomes scarce. Multiple applications competing for an insufficient quantity of physical memory can result in poor performance due to the paging of virtual memory to and from disk.
In order to control distribution of Central Processing Unit (CPU) time for computer applications, a CPU reservation system may be implemented. A CPU reservation system provides a selected amount of CPU time for a computer application during a pre-defined period of time. For example, an application may reserve 1 ms of time every 10 ms. If an application thread touches pageable memory during its allotted CPU time, that thread will stop running while the system pages the memory from disk back into physical memory. In multimedia applications, this may cause the application to fail to complete required processing in time to prevent audio or video glitches from occurring.
In order to avoid difficulties, a realtime application process should not block a synchronization object that is also shared by non-realtime code for at least two reasons. First, if an application attempts to take a memory lock that another application is holding then the application attempting to take the memory lock stops running. Furthermore, if an application blocks during another CPU reservation, it may lose its entire reserved period. A scheduler tries to ensure the smooth running of the CPU reservation system, but if an application blocks, the scheduler may not allow it to run until the beginning of the next cycle. Even if an application doesn't lose its allotted period, it stops running until another application gives up the memory lock. The requesting application process may glitch and may not be able to keep data appropriately fed to hardware. For instance a video card buffer may be unable to remain full and the video card will run out of frames to display on the screen.
Additionally, ready to run threads that are in a CPU reserve will not be scheduled to run if that CPU reserve has completely spent its budget for the current period. Realtime code, or code that is running inside a CPU reserve, may call an Application Program Interface (API) in the system that grabs a synchronization object (i.e.: it takes a lock). If while holding the lock, the reserve runs out of budget, the code in the reserve will be preempted while it is still holding the lock. All other code in the system that tries to acquire that lock will block, and will not be able to run until after the reserve begins its next period and releases the lock. If realtime code holds a memory lock every time it runs out of CPU time, it could detain other applications for an extended period because the other applications cannot obtain the memory lock. Since the threads in the CPU reserve are not visible, the system doesn't see that other applications are blocked.
Accessing pageable memory may cause a page fault. Simply taking a page fault causes more code to run and may cause the realtime code to fail to meet a deadline. The duration of the delay caused by taking a page fault depends upon whether or not the page is present somewhere in physical memory or whether it must be retrieved from disk. A page fault that requires that memory pages be read in from disk is called a hard page fault. A page fault that can be handled without reading a page from disk, is called a soft page fault. Servicing a hard page fault can take on the order of 10 s of milliseconds since the system must wait for the hard disk to read the data and write it into memory. Furthermore the IO for reading that page may be queued up behind other IO which will have to complete first. Taking a hard page fault for a non-present page, for which a disk must be accessed, will cause many low latency realtime tasks to fail to meet their deadlines, as accessing a disk can take up to hundreds of milliseconds.
Although it is possible to write realtime code such that all required memory is allocated at the outset, most applications are not written in this manner. Instead, most applications including multimedia applications allocate memory on demand when they need it. Accordingly, a system is needed for managing memory for realtime threads such that sufficient memory is always present. Realtime threads may have very tight timing requirements that can only be met if the memory they access is always present or locked.